System and method for processing securities trading instructions and communicating order status via a messaging interface

ABSTRACT

A system allowing traders, etc. to use instant messaging (IM) (or other non-FIX based) communications to input trading instructions directly into a broker&#39;s Order Management System (OMS) for managing/executing trades. Accordingly, trading instructions may be provided electronically directly from a buy-side trader, and directly to a sell-side broker&#39;s/brokerage&#39;s OMS, without the need for the sell-side broker to manually re-key the order into the sell-side firm&#39;s OMS. Further, trading instructions are provided in electronic format directly to the broker&#39;s OMS without the need for the buy-side trader to have an expensive FIX based OMS or associated FIX connection, which is also expensive, thereby allowing relatively smaller investment houses/buy-side organizations to enjoy the benefits of electronic delivery of trading instructions directly to brokers&#39; OMS.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of U.S. Provisional PatentApplication No. 60/592,664, filed Jul. 30, 2004, the entire disclosureof which is hereby incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates generally to markets for the exchange ofsecurities, and more particularly to an automated system and method forreceiving and processing securities trading instructions via amessaging, e.g. Instant Messaging (IM), interface and for providingfeedback on order status.

DISCUSSION OF THE RELATED ART

In trading of equities, equity options, fixed income, energy, foreigncurrency derivatives, etc. collectively referred to herein as“securities,” have been traded in this country since the late 1700s.Traditionally, such securities have been traded on floor-basedexchanges, such as the New York Stock Exchange (NYSE) or the AmericanStock Exchange (AMEX). The predominant method of trading in thesefloor-based environments is known as the “open outcry” system, whichinvolves oral communications between market professionals at a centrallocation in open view of other market professionals. In this system, anorder is typically relayed out to a trader standing in a “pit.” Thetrader shouts out that he has received an order and waits until a brokershouts back contract terms, and a trading transaction then results. Inan effort to preserve this antiquated system of floor-based trading, theimplementation of computer-based technology in the exchanges has beenslow. However, some trading processes have been automated or partiallyautomated.

As an example of such automation, many brokers/market professionals,dealers, brokerage houses, etc. (collectively, “sell-side firms”) nowuse an Order Management System (OMS) for sell-side securities trading.An exemplary network environment 10 illustrating an OMS 12 of abrokerage house 20 is shown in FIG. 1. Such an OMS 12 provides agraphical user interface (GUI) via which a market professional 11, 13can execute trades in accordance with the trading instructions via thesell-side broker's computing device 14, 16, such as personal computer,workstation, etc. Such an OMS 12 provides electronic connectivity to theexchanges (not shown) and/or other brokers/brokerage houses (not shown)via a communications network 90 so that trading instructions aretransmitted to computer systems of the exchanges, brokerages, otherbrokers, etc. for processing, such that securities trades may beexecuted in an electronic marketplace/environment. Orders are inputtedinto the sell-side firm's OMS via multiple methods. For example, abuy-side trader 41 can call his/her sell-side broker, requiring thesell-side broker to manually input the trading instructions into thebroker's OMS. Further, a buy-side trader can also send an instantmessage (IM) to his/her sell-side broker, requiring the sell-side brokerto manually input the trading instructions into the broker's OMS. Thebuy-side trader 31 may also have his/her own OMS 30, and if the buy-sideand sell-side firm's OMSs are connected via a specially-configurednetwork, the buy-side firm's OMS may be able to send the order to thesell-side firms' OMS. The data exchange between the two systems may usethe industry standard FIX (Financial Information eXchange) protocol. Asthe sell-side broker executes the buy-side trader's instructions, theorder's status is updated in the sell-side firms' OMS. A typical updateincludes information regarding the number of shares executed and theaverage price for these shares (in the case of an equity securityorder). If the buy- and sell-side firms' OMSs are connected via anetwork, the sell-side firm may send these order updates to the buy-sidefirm's OMS.

The OMS 12 may report execution of trading transactions via Notices ofExecution, e.g. for display via a software based trade blotter. Anexemplary web-based trade blotter 150 is shown in FIG. 6. Variouscommercially available services provide web or other software-basedtrade blotters identifying trading transactions and related tradedetails. One such web-based blotter service is provided by JNKSecurities of New York, N.Y., USA. Various OMSs and related hardware andsoftware, are commercially available and well known in the art, such asthe MarketCenter system manufactured and/or distributed by TradewareSystems, Inc of New York, N.Y., and the Brass system manufactured and/ordistributed by SunGard Worldwide of Wayne, Pa.

Communications and/or instructions communicated to and/or from an OMSare typically formatted and/or communicated according to a standardprotocol that is widely used in the field of financial services. TheFinancial Information eXchange (FIX) protocol is a nearly universalstandard for exchange of such types of information in the securitiesfield. Examples of alternative protocols include FIXML (FIX adapted toXML) and FPML. Accordingly, an OMS provides a useful measure oftechnology-based communication between the various brokers, between abroker and a brokerage, and between a brokerage and other brokerages,the exchanges, etc.

A few technologically sophisticated (usually, relatively large) buy-sidetraders, investment houses/firms, etc. (collectively, “buy-side trader”)have their own OMS 30 permitting a buy-side trader/investmentprofessional 31 to input trading instructions, and otherwise communicatedirectly, with a sell-side brokerage's OMS 12, as shown in FIG. 1. Suchcommunications are made using the FIX protocol discussed above. Becausesuch systems are expensive, relatively few buy-side traders 31, 41 ortheir firms have such OMS systems and/or the dedicated FIX connectionsrequired for their operation.

Accordingly, most sell-side brokers operating and/or interacting with anOMS service buy-side traders that do not have such OMSs, and thus suchsell-side brokers still use inefficient techniques to obtain tradinginstructions from the buy-side traders. For example, an individualinvestor, an investment professional, or other buy-side trader 41 mayplace a telephone call to a sell-side broker 13 and provide oral tradinginstructions. Alternatively, though less frequently, the buy-side trader41 may provide such trading instructions to the sell-side broker 13 byfaxed or other written request, electronic mail (e-mail) message, etc.While this provides some efficiency in communicating with the individualsell-side broker 13, such communications are still ineffective forcommunicating directly with the sell-side broker's/brokerage's OMS 12.Accordingly, the sell-side broker 13 must type or otherwise manuallyprovide input to his OMS to place the corresponding trade into the OMSfor subsequent execution.

A recent development is the use of Instant Messaging (sometimes calledIM or IMing) to communicate instructions to a trader. IM differs fromordinary e-mail in the immediacy of the message exchange and also makesa continued exchange simpler than sending e-mail back and forth. Mostcommunications are text-only. To access an IM service, a user registerswith a service provider and, after connecting to the Internet (or otherappropriate data network), enters the user's screen name and password tolog in to the IM network. Popular IM applications include AOL's InstantMessenger (AIM) and Microsoft's Network Messenger Services (MSN) andYahoo's Yahoo! Messenger. Once a user has logged in to the appropriateIM network, his/her presence on the system is made known to allauthorized partners (commonly termed “buddies”). The user can thenengage in free-form, textual conversations with other IM users connectedto the system.

Because IM is almost completely a text-based service, IM communicationis generally not burdened by the need to transfer large graphic, sound,or program files. As a result, IM communications are truly“instantaneous” under most conditions. Even during peak Internet usageperiods, the delay is rarely more than a couple of seconds. Accordingly,many buy-side traders, and sell-side brokers, have taken to the use ofIM for communication purposes, so that the traders can quickly send, andbrokers can quickly receive, trading instructions. Accordingly, such IMprovides a useful measure of technology-based communication between thebuy-side trader and the sell-side broker. However, such IMcommunications are separate, distinct, and incompatible with, anycommunications with/between OMS systems. Accordingly, a broker must beavailable to type or otherwise provide the trading instructions to theOMS, which introduces delays and opportunities for errors, and increasescosts while decreasing efficiency.

SUMMARY OF THE INVENTION

The present invention provides a system that allows individuals/buy-sidetraders to use instant messaging (IM) (or other non-FIX based)communications to input trading instructions directly into a sell-sidebroker's Order Management System (OMS), so that the sell-side broker maythen work to execute the trade using the brokers OMS. Accordingly,trading instructions are provided electronically directly from thebuy-side trader, directly to the sell-side broker's/brokerage's OMS,without the need for a sell-side broker to manually re-key the orderinto the sell-side firm's OMS. This tends to lower the sell-sidebrokerage's costs of processing the trade, while reducinginefficiencies, delays, errors, etc. Additionally, it is welcomed bybuy-side traders as more convenient, more accurate and faster thanexisting alternatives. Further, trading instructions are provided inelectronic format directly to the sell-side broker's OMS without theneed for the buy-side trader to have an expensive FIX based OMS orassociated FIX connection, which is also expensive, thereby allowingrelatively smaller investment houses/buy-side organizations to enjoy thebenefits of electronic delivery of trading instructions directly tobrokers' OMS.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will now be described by way of example withreference to the following drawings in which:

FIG. 1 is a diagram of an exemplary environment for processing ofinstructions for trading of securities that is representative of theprior art;

FIG. 2 is a diagram of an exemplary environment for processing ofinstructions for trading of securities that is in accordance with thepresent invention;

FIGS. 2A and 2B are block diagrams illustrating exemplary networktopologies in accordance with the present invention;

FIG. 3 is a flow diagram illustrating an exemplary method for processingtrading instructions received via an instant message communication inaccordance with the present invention;

FIG. 4 is a flow diagram illustrating an exemplary method for reportingtrading execution via an instant message communication in accordancewith the present invention;

FIG. 5 is a block diagram illustrating an exemplary server forprocessing instant message communications in accordance with the presentinvention;

FIG. 6 illustrates exemplary IM chat windows, a trade blotter, and anOMS graphical user interface;

FIG. 7 is an image of an exemplary IM chat windows and a speciallyconfigured IM client software window;

FIG. 8 illustrates an exemplary split IM chat window in accordance withspecially configured IM client software; and

FIG. 9 is an image of an exemplary IM client software window that isspecially-configured for sending trading instructions in accordance withthe present invention.

DETAILED DESCRIPTION

The present invention allows buy-side traders to use instant messaging(IM) communications to input trading instructions directly into asell-side broker's Order Management System (OMS), so that the sell-sidebroker may then work to execute the trade using the OMS. Accordingly,trading instructions are provided electronically directly from thebuy-side trader/individual, to the sell-side brokerage's OMS, withoutthe need for a sell-side broker/individual to re-key the order. Inembodiments in which the sell-side broker is actually an automated“bot”, there is no need for human intervention in receiving the IM andprocessing it into the OMS, as discussed in greater detail below.Further, the present invention provides a system capable of allowingsell-side brokers to provide order status communications back to thebuy-side trader without the costs or technological resources associatedwith having a buy-side OMS. Accordingly, after a broker establishes a“presence” on the IM networks, the present invention allows for the useof existing buddy relationships between a buy- and a sell-side user, butprovides for enhanced functionality during the conversations, withoutthe associated delays, inefficiencies, errors, etc.

The present invention may be understood with reference to the exemplary,simplified network environment 50 of FIG. 2, which is similar to thenetwork environment 10 of FIG. 1, but which is further configured inaccordance with the present invention. Similar elements/components aremarked with like reference numerals for ease of reference. Accordingly,it is appreciated that the sell-side brokerage's OMS 12 operates in agenerally conventional fashion, and that a buy-side trader 31 may usehis OMS 30 in a conventional manner to communicate with the sell-sidebrokerage's OMS 12. Further, sell-side brokers 11, 13 may continue tooperate in a conventional manner, and may receive trading instructionsvia telephone, etc. and work trades within the OMS 12 in a conventionalfashion.

However, in accordance with the present invention, a speciallyconfigured Trader Server 18 is provided within the brokerage's network20. In certain embodiments the Trader Server 18 is provided physicallyoutside, but in communication with, the broker's network. As shown inFIG. 2, the Trader Server 18 is logically positioned between thebrokerage's OMS 12 and any buy-side traders 41, and/or their computingdevices 44, wishing to communicate with the brokerage's OMS 12.Optionally, the Trader Server 18 may be logically positioned between thebrokerage's OMS 12 and the brokerage's sell-side brokers 11, 13, and/ortheir computing devices 14, 16.

Accordingly, as shown in FIG. 2, the Trader Server 18 can communicatewith one or more client devices 44 via a communications network 48. Byway of example, the communications network 48 could be a local areanetwork (LAN), wide area network (WAN), an intranet, the Internet, etc.Any network configuration allowing data to flow between points of accessmay be used. In this example, the communications network 48 is theInternet, and the Trader Server 18 is a specially configured server, asdiscussed below. Accordingly, the Trader Server 18 and any clientdevices 44, etc. can communicate with each other via a common protocol,such as a public IM protocol, such as that used by AOL Instant Messenger(AIM®) or a common proprietary protocol, such as that used by IMTrader™of Pivot Solutions, Inc. of Boston, Mass., the assignee hereof. It willbe understood by those skilled in the art that an actual networktopology may include numerous clients and/or servers. The Trader Server18 is discussed in greater detail below with reference to FIG. 5.

Additionally, the Trader Server 18 is optionally configured tocommunicate with the brokerage's existing compliance system 19. By wayof example, such compliance systems 19 record communications betweenbuy-side traders and sell-side brokers, among sell-side brokers, etc.,as generally required by SEC Regulation 17 a-4. For example, IM Managersoftware manufactured/distributed by IMLogic of Waltham, Mass., USA is acommercially available software package that may be used to implement asuitable compliance system. As well known in the art, such compliancesystems may be configured in a straightforward manner to keep records ofIM communications for such purposes.

The buy-side trader 41 may therefore use his client device 44, such as apersonal computer, PDA, internet-enabled mobile phone or the like tocommunicate instant messages via a public or private IM network, to asell-side trader 11, 13, or bot, and thus indirectly to and/or throughthe Trader Server 18. IM communications made via the network 48 for thispurpose are preferably encrypted using 128-bit SSL encryption, orotherwise secured, due to the sensitive financial nature of suchcommunications.

In one embodiment, the client device 44 is configured with standard,commercially available IM client software, such as the AOL InstantMessenger (AIM®) software manufactured and/or distributed by AmericaOnline, Inc., a division of Time Warner, Inc. of New York, N.Y., USA,for sending and receiving instant messages. In such an embodiment,generally available, generally accessible public IM networks, and publicIM software, may be used in accordance with the present invention.Alternatively, the present invention may be configured to interface witha private IM network. To establish the IM functionality, an account withan IM service provider, the required hardware, software and operatingsystem, and a network connection is needed.

In an alternative embodiment, the buy-side trader's client device 44 isconfigured with specially configured IM client software (e.g., IMTrader™software distributed by the assignee hereof) that provides a customizeduser interface whereby the trader may input trading instructionparameters by typing and/or selecting options from specially configuredmenus and/or providing data via a customized GUI. An image illustratingan exemplary GUI of such specially configured IM client software isshown in FIG. 7 (labeled IM Trader) and 9. The specially configured IMclient software may be further configured to provide additionalfeatures, as discussed in greater detail below.

IM communications sent from a buy-side trader 41 are textual in nature,are formatted according to the IM network provider's protocol and areincompatible with the sell-side brokerage's OMS 12. Conceptually, inaccordance with the present invention, the Trader Server 18 receivessuch IM communications and converts them into communications that thesell-side brokerage's OMS can understand, interpret and/or is configuredto accept. Accordingly, the Trader Server 18 effectively converts an IMcommunication to a communication (or responsively creates a newcommunication) that is compliant with the communications protocol usedby the brokerage's OMS 12. In addition to handling of such inboundcommunications (from an IM client to an OMS), the system is capable ofhandling outbound communications (from an OMS and/or to an IM client),as discussed below. In the example, herein, the new/convertedcommunications are compliant with the FIX protocol, althoughconversion/formatting, etc. into any appropriate communication may beperformed in accordance herewith. Network topologies in accordance withthe present invention is shown in greater detail in FIGS. 2A and 2B, andoperation of the Trader Server 18, with respect to the example(s) ofFIGS. 2, 2A and 2B, is discussed below with reference to FIG. 3.

Inbound Communications

FIG. 3 is a flow diagram 100 illustrating an exemplary method forprocessing trading instructions received via an IM communication andother inbound communications (from an IM client to an OMS). Referringnow to FIGS. 2, 2A, 2B and 3, the method begins with receipt of an IMcommunication at the Trader Server 18 via a public or private network48, as shown at steps 101 and 102 of FIG. 3. Transmission and receipt ofthe IM communication may be performed in a conventional manner.Accordingly, a password-protected login procedure may be required forthe buy-side trader to connect and communicate with the Trader Server 18and/or an OMS.

Next, in accordance with the present invention, the Trader Server 18(FIG. 2) scans the IM communication to determine whether the IMcommunication includes, or likely includes, trading instructions, asshown at steps 104 and 106 of FIG. 3. The scanning is performed by theCommunication Scanner module 230 of the Trader Server 18, as shown inFIG. 5. For example, the Communication Scanner module 230 may examinethe sender-supplied text of the message to identify one or more of apredetermined set of keywords, e.g. “buy”, “sell”, “limit”, “edit”,“cancel” or other terms, or synonyms/alternatives thereof (e.g. “b” for“buy”, “s” for “sell”, etc.), typically included in tradinginstructions, and relating to instructions for a trader and/or to becarried out by an OMS. The keywords may include, e.g. “algo”, to provideinstructions to initiate an algorithm-based trade, e.g., such as avolume weighted average price (VWAP) or time weighted average price(TWAP) algorithm, such algorithm-based trades being known in the art. Byway of example, if any of these terms are found in the IM communication,the Communication Scanner module 230 may conclude that the IMcommunication includes trading instructions that will be forwarded to anOMS. Any suitable scanning technique may be implemented, as will beunderstood by those skilled in the art.

If it is determined that the IM communication does not include tradinginstructions in step 106, then the IM communication is simplytransmitted, i.e. allowed to pass, to the intended recipient, as shownat step 118, and no further action is required in connection with thepresent invention. Optionally, the communication may be logged by thecompliance system 19 (FIG. 2) by storing a copy, etc., in compliancewith SEC 17 a-4.

If, however, it is determined in step 106 that the IM communication doesinclude trading instructions (e.g., place, edit, or cancelinstructions), then the method continues with parsing of the IMcommunication to identify trade parameters of the trading instructions,as shown at step 108. This parsing may be carried out by InboundProcessor module 232 of the Trader Server 18 shown in FIG. 5. Anysuitable parsing technique may be used as will be appreciated by thoseskilled in the art. In one embodiment, buy-side traders are permitted tocompose free-form, natural language IM communications that include theirtrading instructions. For example, the substance of the IM communicationmay be “Bob, I'd like to buy some IBM stock—please buy for me 100 sharesat the market price.” Any of various known techniques may be used toexamine the content of such a natural language IM communication andextract relevant terms believed to be trade parameters. In this example,the parsing may result in interpretation of the IM communication toinclude trading instructions to buy 100 shares of IBM at the marketprice.

In an alternative embodiment, buy-side traders are encouraged to composeIM communications for trading purposes that have a predefined cadence,and the Inbound Processor module 232 of the Trader Server 18 (FIG. 5) isconfigured to expect such a cadence. For example, a prescribed sequenceof terms/variables formatted in a certain manner may be required orpermitted as a predefined cadence. By way of further example, theprescribed sequence may be:

Side Quantity Ticker Ordertype Limitamt Note.

Accordingly, if an IM communication were received that read “OK, I'dlike to buy 10,000 IBM limit 98”, the Inbound Processor module 232 ofthe Trader Server 18 (FIG. 5) would identify the cadence “buy 10,000 IBMlimit 98”, where SIDE=buy, QUANTITY=10,000 shares, TICKER=IBM,ORDERTYPE=limit, LIMITAMT=$98, and note=[nothing]. More specifically,the cadence may require parsing to identify each trade parameter,namely: a SIDE parameter indicating a side of the transaction, whichmust be the first term in the cadence, and which must be selected fromthe list: buy, sell, cover (buy), short; a QUANTITY parameter, whichmust be numeric, and may include logic to convert abbreviated orconfusing quantities (e.g. 10 k, or 10,000 or 10000) into a numericalformat expected by an OMS, e.g. 10000; a TICKER parameter, which may bean unrestricted field, an ORDER TYPE parameter, which must be selectedfrom the list mkt/market=mkt, lmt/limit/top/low=lmt; a LIMIT AMOUNTparameter, which must be numeric, and a NOTE parameter, which may beoptional. Optionally, additional functionality may be provided to allfor editing and canceling of orders, managing sending and/or receipt ofnotices of execution, etc. Any suitable cadence, or multiple cadences,may be used.

Optionally, if a keyword is found, but values for one or more expectedtrade parameters are missing, the system may enter a Q&A mode in whichindividual IM communications are sent by the system that request thesender to enter values for parameters. For example, if the originalcommunication included only “buy”, subsequent IM messages may be sent asfollows “Enter quantity”, “Enter ticker”, etc. until values for allrequired trade parameters have been obtained.

After the trade parameters have been identified from an inbound IMcommunication (that is, an IM communication being sent to an OMS), theOutbound Communication Composer module 234 of the Trader Server 18 (FIG.5) creates an order confirmation communication that includes the tradeparameters, as shown at step 110. The order confirmation communicationmay have any suitable format, but is preferably composed as an IMcommunication directed to the buy-side trader that sent the IMcommunication including the trading instructions, and that originatedfrom the sell-side trader that received the instructions. The orderconfirmation preferably includes text asking the recipient to confirmthe trade parameters as understood by the Trader Server 18. For example,the order confirmation communication, when displayed via the buy sidetrader's IM client device, may have the form:

Buy 10000 IBM LMT 98? Respond now with Yes or No.

If it is determined that the order confirmation is not correct (e.g. byreceipt via a responsive IM communication including the text “N” or“No”), the method ends, as shown at steps 112 and 119 of FIG. 3. Thismay be followed by a new IM communication including correct tradinginstructions, at which point the method would repeat from step 101. Itwill be appreciated by those skilled in the art that additionalfunctionality may optionally be provided to, for example, ask the userfor clarification, e.g., If “no”, what is not correct? Please respondwith side (s), quantity (q), ticker (t), order type (o), limit amount(I) or cancel further processing (c). In addition, an “expert mode” maybe provided in which the server may not ask for a confirmation. Thesemessages are outbound communications, and may be handled by the OutboundCommunications Composer module 238, as discussed in detail below.

If however, it is determined that the order confirmation is correct(e.g. by receipt via a responsive IM communication including the text“Y” or “Yes”), then the Inbound Communication Composer module 234 (FIG.5) of the Trader Server 18 creates an OMS protocol compliant ordercommunication reflecting the trade parameters, as shown at step 114.Additional logic may be employed to handle other responses, or a lack ofa timely response. This order communication is comparable to an ordercommunication sent from or to an OMS for processing by another OMS, andmay be in any suitable format and/or prepared according to any suitableprotocol. The particular protocol used will depend upon the protocolused by the OMS with which it is desired to be compatible.

For example, an order communication compliant with the FIX protocol maybe created in step 114, for communication to a FIX-compliant OMS.Accordingly, this requires a mapping of fields in the cadence/IMcommunication to fields according to the FIX protocol, such that thetrade parameters supplied via the IM communication can be presented inthe appropriate fields of the FIX protocol order communication, and suchthat the FIX protocol order communication will be properly understood bythe OMS. Advantageously, in this example, a dedicated FIX connection isrequired only between the sell-side brokerage's OMS 12 and the sell-sidebrokerage's Trader Server 18, and yet numerous different buy-sidetraders can communicate with the brokerage's FIX-compliant OMS withoutthe need for such buy-side traders to have a FIX connection, or aFIX-compliant OMS. Instead, a buy-side trader only requires conventionalIM communication hardware and/or software, and/or specially configuredIM client software.

Consider again the example above, which includes the tradinginstructions BUY 10000 IBM LIMIT 98. This information, as interpreted bythe Trader Server 18, is represented in the table below:

IM Server Field Value Side: BUY Quantity: 10000 Ticker: IBM Order Type:Limit Limit Amount:   98 Trade Status: New Filled Amount:   0

This information may then be mapped to the corresponding FIX fields forcreating of a corresponding order in accordance with the FIX protocol,as represented in the table below.

Trader Server Field Value FIX field No.: Description Side: BUY 54: SideQuantity: 10000 38: OrderQty Ticker: IBM 55: Symbol Order Type: Limit40: OrdType Limit Amount:   98 44: Price Order Status: New 39: OrdStatusFilled Amount:   0 14: CumQty

As will be appreciated by those skilled in the art, this simpleillustrative example may be included as part of a tag=value style FIXmessage as follows:

8=FIX.4.2̂9=251̂35=D̂49=AFUNDMGR̂56=ABROKER̂34=521̂52=2003061509:30:47̂11=123456̂1=26522154̂55=IBM̂48=459200101̂22=1̂54=2̂60=2003061509:30:47̂38=10000̂40̂2̂44=98̂10=127

By way of further example, such information may be incorporated as partof a FIXML communication as follows:

<FIXML> <NewOrdSingle CIOrdID=“123456” Side=“2”TransactTm=“20030615T09:30:47-05:00” OrdTyp=“2” Px=“98” Acct=“26522154”><Hdr Snt=“20030615T09:30:47-05:00” PosDup=“N” PosRsnd=“N” SeqNum=“521”><Sndr ID=“AFUNDMGR”/> <Tgt ID=“ABROKER”/> </Hdr> <Instrmt Sym=“IBM”ID=“459200101” IDSrc=“1”/> <OrdQty Qty=“10000”/> </NewOrdSingle></FIXML>

Creating an order communication that is properly formatted, carries thecorresponding trade parameters in the appropriate fields, and isotherwise FIX protocol compliant is straightforward, as will beappreciated by those skilled in the art. A more detailed description ofthe FIX protocol is provided on the fixprotocol.org website.

The order communication is then transmitted from the Trader Server 18 tothe brokerage's OMS system 12 (FIG. 2), as shown at step 116 of FIG. 3.In other words, the Trader Server 18 inserts a new FIX message into theOMS database. Additionally, the IM message is transmitted to theintended recipient (sell-side broker) and is displayed on the sell-sidebroker's display screen, as shown at steps 118 and 119. A third-partyFIX engine of the OMS monitors the message queue in the database andperforms the required actions as dictated in the FIX message.Transmission of the FIX-compliant, or other, communication may beperformed in a straightforward manner, as will be appreciated by thoseskilled in the art. The sell-side broker receives the buy-side tradersIM and thus is kept informed of the transaction. Optionally, anauthentication step is included in which it is confirmed that the senderof the trading instructions has been given permission to trade over IMvia the sell-side firm's server/system. For example, meta informationrelated to the buy side trader may include identification of which firmthat IM buddy belongs to so the order can be placed properly in the OMS.Further confirmatory or other information may be included, such as adate and time of a trade. FIG. 6 illustrates exemplary IM chat windows140, 142, a trade blotter 150, and an OMS GUI window 160, and shows therelationship of exemplary data exchanged between same.

After the order communication is received by the OMS, processing of thetrade continues in a conventional manner. For example, this may includethe OMS's acceptance and/or acknowledgement of the order communication,display of the corresponding order in via a GUI window of the OMS, thesell-side broker's acceptance of the order in the OMS, etc. As thetrader executes one or more trading transactions in fulfillment of theorder, one or more Notices of Execution (NoEs) may be sent to thebuy-side trader.

Outbound Communications

In accordance with the present invention, transactions are reported,e.g. via NoEs, to the buy-side trader via an IM outbound communication(that is, from an OMS and/or to an IM client). FIG. 4 is a flow diagram120 illustrating an exemplary method for reporting trading execution (orother communications outbound from an OMS) via an IM communication.Similarly to the inbound communications (from an IM client to an OMS)processed above, these outbound communications (from an OMS to an IMclient) are processed in an automated fashion and deliveredelectronically from the sell-side brokerage's OMS 12 through the TraderServer 18 directly to the buy-side trader's client device 44, withoutthe need for human intervention. As shown in FIG. 4, the method startswith receipt from the OMS 12 (FIG. 2) of an OMS protocol compliant, e.g.FIX compliant, verification communication containing trade details(e.g., an NoE) at the Trader Server 18 (FIG. 2), as shown at steps 121and 122 of FIG. 4. This communication may be prepared and sent by an OMSin a conventional manner, as will be understood by those skilled in theart. This communication is placed in a queue that is monitored by theTrader Server 18. For example, when a fill is entered for a particularorder, a FIX verification communication is received at the Trader Server18 from the broker's OMS 12. The FIX communication is placed in theincoming message queue, which is monitored by Trader Server.

Next, the Outbound Processor module 236 of the Trader Server 18 (FIG. 5)parses the verification communication originating from the OMS, which inthis example is FIX compliant, to identify the pertinent trade details,as shown at step 124. In the example above, such parsing may identifythat the buy order for 10,000 shares of IBM at a limit of $98 has beenfilled. It is noted that the trade details may not be identical to thetrade parameters. For example, the trade details may indicate that sofar, only 6,000 shares of IBM have been purchased at $98/share. Inaddition to the execution quantity (e.g. 6,000), the trade details maytherefore further indicate the remaining quantity to be filled (e.g.4,000), an order identification number, average share price, and/orother pertinent transaction details.

The Outbound Communication Composer module 238 of the Trader Server 18(FIG. 5) next creates an IM communication including the trade details,as shown at step 126. This may be performed by the server creating amessage that is sent to the IM Gateway's API software in astraightforward manner, as will be understood by those skilled in theart. The IM communication is then transmitted to the buy-side trader 41via an IM network 48 (FIG. 2) in a conventional manner and the methodends, as shown at steps 128 and 129 of FIG. 4. In the context of theexample above, the textual content of the IM communication may read“Update for Buy 10,000 IBM LMT 98: filled 6,000 @ 98, 4,000 leaves”.This IM communication containing trade details is delivered to andviewable by the buy-side trader 41 via his client device 44 (FIG. 2)from the sell-side broker, and it is also viewed on his client device.Accordingly, both parties in the conversation see the message; though itis sent from the sell-side Trader Server, it echoes back and is viewableon the sell-side broker's display screen.

Trader Server

FIG. 5 is a block diagram of a Trader Server 18 (see FIG. 1) inaccordance with the present invention. The Trader Server 18, whichincludes conventional server hardware storing and executing speciallyconfigured computer software for carrying out a method in accordancewith the present invention. By way of example, the Trader Server 18 maybe implemented as a specially configured server, which may optionallyinclude the FIX Gateway and/or the IM Gateway. By way of example,conventional server hardware including an Intel Xeon 2.8 GHz processorwith a 512 k cache and running Red Hat Enterprise Linux ES Basic Editionor any typical Microsoft Windows server software (2000, 2003, etc.),having 1 GB RAM and 36 GB of hard disk memory, a dual port networkadapter, floppy disk drive and CD-ROM drive has been found suitable forthis purpose. Further such conventional hardware is configured with thespecially configured server software for performing the functionalitydescribed above. The server is configured for communication via IMnetwork. By way of example, the server may be configured with a Jabberopen source solution, or IM Linkage software manufactured and/ordistributed by IMLogic of Waltham, Mass. for this purpose. Further, theserver includes software that connects the system to a FIX network.There are numerous applications that will allow an OMS to connect to andcommunicate via a FIX/FIXML network. The server software may be writtenin Java or other programming languages to provide the messaging, storingand processing of the messages between the public IM and FIX networks.

Accordingly, the Trader Server 18 of FIG. 5 includes a general purposemicroprocessor (CPU) 202 and a bus 204 employed to connect and enablecommunication between the microprocessor 202 and the components of theTrader Server 18 in accordance with known techniques. The Trader Server18 typically includes a user interface adapter 206, which connects themicroprocessor 202 via the bus 204 to one or more interface devices,such as a keyboard 208, mouse 210, and/or other interface devices 212,which can be any user interface device, such as a touch sensitivescreen, digitized entry pad, etc. The bus 204 also connects a displaydevice 214, such as an LCD screen or monitor, to the microprocessor 202via a display adapter 216. The bus 204 also connects the microprocessor202 to memory 218 and long-term storage 220 (collectively, “memory”)which can include a hard drive, diskette drive, tape drive, etc.

The Trader Server 18 may communicate with other computers or networks ofcomputers, for example via a communications channel, network card ormodem 222. The Trader Server 18 may be associated with such othercomputers in a local area network (LAN) or a wide area network (WAN),and operates as a server in a client/server arrangement with anothercomputer, etc. Such configurations, as well as the appropriatecommunications hardware and software, are known in the art.

The Trader Server's software is specially configured in accordance withthe present invention. Accordingly, as shown in FIG. 5, the TraderServer 18 includes various software-implemented components, including aCommunication Scanner module 230 for scanning IM communications receivedfrom a buy-side trader to determine whether such communications likelyinclude trading instructions, an Inbound Processor module 232 forparsing an IM communication received from a buy-side trader to identifytrade parameters from an IM communication, an Inbound CommunicationComposer module 234 for creating an OMS protocol compliant communicationincluding the trade parameters and transmitting it to an OMS, anOutbound Processor module 236 for parsing an OMS protocol compliantconfirmation communication to identify trade details, and an OutboundCommunication Composer module 238 for creating an IM communicationincluding the trade details and transmitting it via a communicationsnetwork. These components are shown logically in FIG. 5 for illustrativepurposes, without regard to any particular embodiment in one or morehardware or software components. The Inbound Processor module 232 maycommunicate directly with the Outbound Communication Composer module 238for receiving and sending confirmatory IM communications.

Optionally, the server hardware includes software for connecting to thethird-party IM networks, such as Jabber (open source) or IM Linkagesoftware by IMLogic, Inc of Waltham, Mass. Preferably, all IM tradingmessages are logged in the Trader Server's database to ensure all IMmessages can be sent to the compliance server 19.

The Trader Server 18 connects an Instant Messaging network to a FIXnetwork. It does this by listening for events from either network, andtaking appropriate actions when an event occurs. For example, one typeof event could be the arrival of an IM communication.

Software programming code for carrying out the inventive method istypically stored in memory. Accordingly, the Trader Server 18 stores inits memory microprocessor executable instructions including programs forcarrying out the method described above.

Additionally, computer readable media storing computer readable code forcarrying out the method steps identified above. The computer readablemedia stores code for carrying out subprocesses for carrying out themethod described above.

A computer program product recorded on a computer readable medium forcarrying out the method steps identified above. The computer programproduct comprises computer readable means for carrying out the methoddescribed above.

Specially Configured Im Client Software

As discussed above, the buy-side traders client device 44 may optionallybe configured with specially configured IM client software 44 a insteadof conventional, commercially available IM client software. In additionto permitting a user to send IM communications, such speciallyconfigured IM client software may provide the ability to connect tomultiple, different IM networks, such as AOL, MSN, etc. and to displaycorresponding chat windows for each network within a single clientwindow, such that multiple IM communications sessions may be viewedconcurrently within a single client software application, as shown inFIG. 7. This is contrary to existing IM client software that providesfor conducting and/or viewing chat for only a single communicationsession. Further, such specially configured IM client software mayprovide for a broadcasting feature, whereby a single IM message may beselectively delivered to multiple recipients, and/or a quick-replyfeature, whereby frequently used responses/instructions/commands areavailable for quick selection from a menu.

Further, such specially configured IM client software may be configuredto provide a split chat window whereby IM communications between thesell-side broker and others, e.g. the buy-side trader, are viewed in awindow that is separate from IM communications sent or received in anautomated fashion to or from the sell-side broker's Trader Server, asshown in FIG. 8.

Exemplary System Operation

By way of further example, operation of the system is described asfollows with reference to FIGS. 2A and 2B. The Trader Server 18 runningtrader server software 18 a in accordance with the present inventioninteracts with the trader client 44 a, the IM Gateway 46 and the FIXGateway 70, as best shown in FIG. 2A and 2B. The IM Gateway 70incorporates commercially available software, such as Jabber or IMLinkage from IMlogic, among others. The FIX Gateway 70 sends a messageout to the FIX networks. The FIX Gateway 70 uses the FIX protocol, whichis well known to those in the art. The Trader Server described hereininterfaces with the FIX server so that industry standard protocolmessages can be sent over various third party FIX networks. When the IMGateway 70 is started, a call-back function is established back to theTrader Server. This allows the IM Gateway 70 to contact the TraderServer 18 whenever an event occurs. For example, when the IM Gateway 70server receives a message from one of the Public IM networks, it“calls-back” to the Trader Server 18 that an event has occurred andpasses along the received message. The call-back function passes themessage along to the Communication Scanner 230, FIG. 5.

The Communication Scanner 230 reviews the contents of the messageagainst the known sets of predetermined trading keywords and cadences.If the Communication Scanner 230 recognizes a keyword or cadence in themessage, the message is sent to the Inbound Processor 232, FIG. 5, forparsing. In this exemplary embodiment, the Inbound Processor 232 removesany extraneous information from the message that is not needed forparsing the instant message into a trading message, and assigns a uniquemessage identifier to each message for internal tracking purposes.

The Inbound Processor 232 then determines what actions to take as afunction of the keywords found within the message. For example, if themessage includes “buy”, “sell”, “short”, “cover”, etc., then a new tradeinstruction will be created. If the message includes “edit” or “cancel”,an edit trade or cancel trade instructions will be created,respectively. Further, if the message includes “place”, aplace/acknowledge instruction will be created. As described above, theInbound Processor 232 may be configured to operate on synonyms,abbreviations, etc. of keywords in its processing.

Based on the keyword found, the Inbound Processor 232 compares knowncadences to the message body. The Inbound Processor parses the messageinto various data tokens, which are clusters of data, typically taken tobe any data between consecutive “space” characters. However, the InboundProcessor 232 is also capable of breaking a message into tokens withoutspaces. The data type for each token is determined, such as whether thetoken is of text or numeric type. Based on the keyword, the InboundProcessor 232 begins to determine which of the tokens are applicable forthe current cadence set. For example, if the cadence is “side quantityticker order type limit amount” with an associated data type of “text”“numeric” “text” “text” “numeric” for the tokens associated with thecadence, that will assist the Inbound Processor 232 in matching the listof known cadences to the data. Once the Inbound Processor 232 is able tomatch a message to a known cadence, the message's tokens are mapped tothe corresponding FIX Gateway's message format using the InboundCommunication Composer 234.

The FIX Gateway 70 of FIG. 2B includes commercially available softwareenabling connection to a network to another system so that the InboundCommunication Composer 234 attaches to the FIX Gateway 70. The FIXGateway 70 is interposed between the Trader Server 18 and a FIX network,to which is connected an OMS 12. In an alternative configuration, theInbound Communication Composer 234 is directly connected to an OMS usinga database connection such as ODBC. This alternative configuration maybe used with OMSs, that permit direct database connectivity with outsidesystems. The Inbound Communication Composer 234 composes a message thatis appropriate for the system being interfaced, depending upon theTrader Server's configuration and connections. The Inbound CommunicationComposer 234 calls the FIX Gateway's API or database connection to sendthe message to the FIX Gateway or database. The Inbound CommunicationComposer's message is preferably normalized, so that the same message iscreated regardless of whether the message originated from an Order EntryTicket or an IM message.

For example, a message for a new trade to buy 50,000 shares of IBM atthe market, whether it originated from trader client's new order entryor an instant message, will look virtually identical when the message ispassed from the Inbound Communication Composer 234 to the FIX Gateway(or directly to the OMS through a database connection). This message maybe input via an exemplary proprietary trader client 44 a that allows forsending of IM messages to the Trader Server 18. An exemplary proprietarytrader client's order entry screen 85 is displayed in FIG. 9 and isdiscussed in greater detail below. Alternatively, the message may beinitiated via a conventional IM message that includes the text, e.g.“buy 100 tst mkt “note: please work ASAP”. Regardless of the method ofinput, the message from the Inbound Communication Composer 234 will besimilar when it interfaces with external systems. In one embodiment, themessage is sent to the Trader Server using an XML-formatted message overa secure SSL socket connection. Alternatively, submission via a webservice may be used instead of the secure socket connection.

By way of further example, after authorized users have been establishedfor use of the Trader Server, an exemplary communication session betweenan IM Gateway and a FIX Gateway transpires as follows. First, a user(User 1) attaches to the IM Network, such as AOL's Instant Messenger,using the IM Network Providers' software, such as the AOL InstantMessenger (AIM) client software. Next, another user (User 2) attaches toIM Network via the trader client software by connecting to the TraderServer, which is connected to the IM Client's network (the AOL InstantMessenger network) through the IM Gateway Server. User 1 and 2 areconnected to the IM Network until they disconnect or log out. User 1then enters a message in IM client to User 2, for example “I want tosell 40 k MOT mkt”. The message then travels through IM client's network(such as the AOL Instant Messenger network). The public IM Network sendsa message to User 2 via the IM Gateway. The IM Gateway receives thismessage and uses a call-back function to send the message to the TraderServer's Communication Scanner. The Communication Scanner searches allincoming messages for keywords and finds the keyword “sell.” Because akeyword was found, the message is sent to the server's InboundProcessor. The Inbound Processor normalizes any keywords such as “k” or“000” to “000”, as in 1 k to 1000, as well as synonyms such as “b” for“buy”. The Inbound Processor finds the keyword(s) and breaks messageinto tokens surrounding the keyword(s). The tokens are assigned datatypes (such as text or numeric), and the Inbound Processor appliescadence rules to token set(s). The Inbound Processor next matches publicIM Buddy ID in the Trader Server to get other information about thatBuddy ID such as their firm and permission settings. If the Buddy ID isprovisioned and permissioned to trade, the process continues. The TraderServer associates the IM Buddy Name with the name of an actual trader,the name of their associated firm and any codes associated with thefirm. The Trader Server is aware of the broker's firm name andassociated code. Next, the Inbound Processor matches the token set toFIX fields, and sends a message to the Outbound Communications Composer.The Outbound Communications Composer creates a message compatible withthe FIX Gateway, and calls the FIX Gateway's API to send the FIX messageto the FIX Network. Finally, the original IM message sent by User 1 isdisplayed in User 2's trader client software. Users can cancel and editorders in a similar manner.

In certain embodiments, the Communication Scanner module 230 examinesthe sender-supplied text of the message to identify one or more of apredetermined set of keywords that are instructions of an additionaltype, namely, a type that will not likely be forwarded to or carried outby the OMS. Instead, the Trader Server, or another system componentother than the OMS, acts upon these instructions. The Inbound Processor232 determines what actions to take as a function of the keywords foundwithin the message. By way of example, these keywords may include“blotter”, “research”, or synonyms/alternatives thereof. An IM messageincluding these keywords may be parsed in a manner similar to thatdescribed above to identify related parameters, etc. However, the TraderServer, e.g. via the Inbound Processor 232 discussed below, initiates aresponse to these commands without a need to send instructions to anOMS.

For example, if the message includes the word “blotter”, the appropriateblotter actions will be taken. By way of example, a database may bemaintained at the Trader Server to keep a record of all tradinginstructions, confirmatory messages, notices of execution, etc., andreceipt of the blotter command will result in the Trader Server'sreferencing of that database, compiling of the requested blotterinformation, and transmitting of a message, e.g. IM message, back to theparty sending the blotter request. More specifically, the system may beconfigured to display a user's trade blotter (identifying the list oftrades, number of shares placed/filled, average price paid per share,etc.) when the keyword “blotter” is included in the message, e.g.“what's my blotter”. In this embodiment, this results in a reply to themessage with a blotter. This system operates in a manner similar to thatdescribed above, but once the Inbound Processor finds the “blotter”keyword, the system looks to its internal database for orders. Theinternal database is kept in sync with the FIX message in accordancewith the present invention. The internal database is read, and theappropriate data from the database is selected. Accordingly, it is notnecessary to send information to the OMS to respond to this command.This data is then transformed into a text string which is sent to the IMGateway via the IM Gateway's API. The outbound message sent to the userover IM may include the order number, side, quantity filled, averageprice, and number of leaves (quantity ordered—quantity filled).Exemplary output is shown below

“Here's is your Blotter (3 placed, 0 unplaced trades):

#1 Buy 25,000 IBM LMT @ 92.25: Filled 20,000 @ 92, 5,000 leaves.

#2 Sell 45,000 CSCO MKT: Filled 45,000 @ 22.45, 0 leaves

#3 Short 40,000 WMT LMT @ 55.44: Filled 0 @ 0, 40,000 leaves”

By way of further example, if the message includes “research”, then anIM or other communication including previously compiled financialresearch information and/or a URL to a brokerage's research reports fora particular ticker may be send via a responsive IM message when a“research [ticker]” string is sent. Such information may be retrieved,for example, from a database maintained Ideally at the Trader Server, orelsewhere, without the need to send information to or gather informationfrom an OMS.

In an exemplary embodiment, the FIX Gateway 70 includes Trader's Consolesoftware manufactured and/or distributed by Eze Castle Software ofBoston, Mass. In this embodiment, data is inserted and/or read from atable in Trader's Console that is continually monitored for changes.When a change is detected, a FIX message is sent out from Trader'sConsole to the FIX Gateway, such as Coppelia, from Javelin Technologiesof New York, N.Y. Accordingly, the IM messages, once translated by theTrader Server 18, are inserted into/read from a table in Trader'sConsole that is used to interact with the FIX Gateway. Thus, the serveraccesses the databases within Trader's Console, which in turn interactwith the FIX Gateway. Most Order Management Systems (from vendorsincluding Macgregor of Boston, Mass., Charles River Development ofBoston, Mass., Bloomberg LP of New York, N.Y., SunGard of Wayne, Pa. andAdvent Software of San Francisco, Calif.) include a FIX Gatewaycomponent that may be interfaced with in a corresponding manner.

Miscellaneous

Although reference has been made herein for illustrative purposes toimplementation and/or use of the present invention by sell-side brokers,it is contemplated herein that the IM Server and/or the concepts of thepresent invention may be implemented by buy-side traders/investmentfirms or others. Further, it will be appreciated that the presentinvention allows a user to negotiate their quantity and limit using IMas a transport mechanism. For example, the user might express an orderfor 50 k IBM limit 98. The system could match this order with otherorders in the broker's book. For example, the broker may have an orderfor 40 k IBM limit 99. The Trader Server may be configured to provide anautomated negotiation between the two parties using IM as the transportto negotiate the price and quantity of the order.

Further, the present invention may be used for Indication of Interest(IOI) support, e.g. with respect to a firm wanting to express interestin taking/leaving a position. Accordingly, the present invention isapplicable to indications of interest that are not definite orders. Inthis context, the Trader Server allows the user to enter an IOI usingvia the trader client. For example: “I'm a large buyer of IBM today” or“ioi: 50 k IBM to buy”.

Further still, the system may be configured with a bot for receivingtrading instructions apart from any human brokers, such that buy sidetraders can communicate IM messages directly to a bot “buddy” on the IMnetwork. By way of example, the sell-side firm may create a “bot”presence on the IM network. A bot is a “buddy” in the IM context that isconnected to an IM network, but as computer or process, not a human.When a buy-side trader places trading instructions with a bot, bysending an IM message to the bot, the instructions are sent into the OMSwithout any manual intervention or human requirement whatsoever.Accordingly, the bot is configured to act as an automated conduit to theOMS, not requiring the use of an actual sell-side broker.

In addition, each trade, as well as previous positions may be associatedwith a buddy ID using a watchlist. A watchlist can include all stocks abuddy has traded in the past, or is interested in monitoring for futuretrades. For example, if a buddy performs an IBM trade, IBM can be addedto that buddy's watchlist. If another buddy also traded IBM or toldtheir broker they were interested in receiving news about IBM, IBM couldalso be added to that buddy's watchlist. The system could then collectall tickers across all buddy's watchlists to create a new “virtualbuddy” for each unique ticker. In this example, a new virtual buddycalled “IBM” could be created that represents all IM buddies that haveIBM in their watchlist. The broker could then just select the “IBM”virtual buddy from their buddy list, and when a message is sent to thisbuddy, the system would determine which individuals are subscribed tothat ticker by having that ticker in their watchlist, and send themessage to those individuals automatically. This creates an efficientway for the trader to manage which clients are interested in varioussecurities, and send information to these clients quickly. Accordingly,an IM virtual buddy can be used in the IM context as a messagedistribution list of IM buddies to which a message should be sent.

While the description above provides a discussion of IM client to OMScommunication for illustrative purposes, it will be understood by thoseskilled in the art that the present invention encompasses othercommunications to and from OMS, via other communication networks, suchas the World Wide Web and email. Accordingly, for example, the TraderServer may be configured to allow a buy-side trader to email an order totheir sell side broker using an email communication incorporating textthat is similar to the cadences discussed with regards to IM (such asbuy 30,000 IBM LMT 98). Therefore, just as IM to FIX communications aredescribed in detail above, the Trader Server may be alternativelyconfigured to handle SMTP to FIX, and vice versa, communications in thee-mail context, or HTML to FIX, and vice versa, communications in theWeb context. The Trader Server could also be configured to send out endof day email summaries of the buy-side trader's trades, or their entireblotter. These IM, Web and email communications could also be in theform of an attachment, for example, in a format understood by Excel®, aspreadsheet application produced by Microsoft Corporation of Redmond,Wash. that could be created/read by the Trader Server.

Further, it is noted that the illustrative discussion above emphasizesfor illustrative purposes an embodiment in which inbound communicationsare translated from IM to FIX, and that related outbound communicationsare translated from FIX to IM. However, it will be appreciated thatthese communications are wholly separate and independent. For example,it should be understood that trading instructions may be sent from a buyside trader by a verbal telephone communication, and yet a correspondingNotice of Execution may be sent from the broker's OMS to the buy sidetrader in IM, involving a FIX to IM conversion. Furthermore, the tradinginstructions can be sent to a broker by FIX or IM, and then NOEs couldbe sent via both FIX and IM back to the buy-side. Accordingly, a buyside trader's IM communication may be converted to FIX, and then be sentnot only to the sell-side broker's OMS, but also to the buy sidetrader's OMS, thereby allowing the buy side trader to track transactionsoriginated by IM communication via the buy side trader's OMS. In oneembodiment, a choice of communication channel used for eachcommunication could be based on a “preference engine” that provides aprofile for each customer that would “know” the best way to route amessage, such that all communications for a given buy side trader arereported via IM, for example.

In a certain embodiment, certain additional functionality is provided inrelation to the virtual buddies described above. More specifically, themarket data and data from other data bases are integrated when creatingvirtual buddies. For example, the Trader Server is configured to receivea data feed, e.g. from Bloomberg or Reuters, of the most actively tradedstocks on the various exchanges (such as the New York Stock Exchangeand/or NASDAQ) and to update Virtual Buddy Groups to reflect such data,such as a group called “NYSE Most Active”, “NASDAQ Most Active”, etc. Inthis buddy group, the Trader Server determines which tickers are themost actively traded tickers (using a method supplied by the market datavendor), in that group. Then, the system would match the most activetickers with tickers across various distribution lists. This allows thetrader to contact buddies that have the most active tickers in theirwatchlist in an expedient manner. Accordingly, dynamic distributionlists are created and maintained that have an awareness of the tradeblotter as well as other market data.

Additionally, other important market data, such as largest gain/loss instock price or largest percent gain/loss may be incorporated. Othermarket data could also include items such as tickers that have earningsconference calls today, tickers that have been upgraded/downgraded orfrequently mentioned in news stories.

The virtual buddies could also be sorted using various methods, such astotal number of shares owned by clients, tickers traded most recently orother sort terms as appropriate.

Further, it should be noted that the functionality of the Trader Servermay be accessed using an API of its own. For example, a developer at thebroker could write a program that accesses the Trader Server to obtain awatchlist, send IMs to a watchlist, etc. This API facilitatesincorporation of the Trader Server into other software solutions.

Having thus described particular embodiments of the invention, variousalterations, modifications, and improvements will readily occur to thoseskilled in the art. Such alterations, modifications and improvements asare made obvious by this disclosure are intended to be part of thisdescription though not expressly stated herein, and are intended to bewithin the spirit and scope of the invention. Accordingly, the foregoingdescription is by way of example only, and not limiting.

We claim:
 1. A method comprising: generating a receipt of an inboundcommunication; scanning the inbound communication for an instruction;when the inbound communication does not include the instruction,forwarding the inbound communication to an intended recipient; and whenthe inbound communication does include the instruction, parsing one ormore trade parameters from the inbound communication.
 2. The method ofclaim 1, wherein the instruction is a trading instruction.
 3. The methodof claim 1, wherein the instruction is a buy order.
 4. The method ofclaim 1, further comprising: performing a protected login procedure forthe inbound communication.
 5. The method of claim 1, wherein theinstruction includes a keyword selected from the group of buy, sell,limit, edit, cancel, or any synonym thereof.
 6. The method of claim 1,wherein the instruction includes a volume weighted average price (VWAP)or time weighted average price (TWAP) algorithm.
 7. The method of claim1, further comprising: logging the inbound communication according to acompliance procedure.
 8. The method of claim 1, wherein the tradeparameter includes a side, a quantity, a ticker, an order type, and anamount.
 9. The method of claim 1, further comprising: generating anoutbound communication in response to a missing parameter.
 10. Themethod of claim 9, further comprising: receiving a second inboundcommunication included data indicative of the missing parameter inresponse to the outbound communication.
 11. The method of claim 1,further comprising: displaying a window having a boundary defining aperimeter of the window, the window comprising a plurality of distinctdisplay areas disposed internal to said boundary, the plurality ofdisplay areas comprising: a first display area configured to display afirst chat text corresponding to a first chat session via a firstinstant messaging (IM) network; and a second display area configured todisplay a second chat text corresponding to a second chat session via asecond IM network, the second IM network being different from the firstIM network.
 12. The method of claim 1, further comprising: convertingthe one or more trade parameters from the inbound communication to apredetermined protocol.
 13. An apparatus comprising: a network interfacedevice for communicating via a communications network and configured toreceive an inbound communication; a processor configured to scan theinbound communication for an instruction, the processor furtherconfigured to, when the inbound communication does not include theinstruction, forwarding the inbound communication to an intendedrecipient, and the processor further configured to, when the inboundcommunication does include the instruction, parsing one or more tradeparameters from the inbound communication.
 14. The apparatus of claim13, wherein the instruction is a trading instruction.
 15. The apparatusof claim 13, the processor further configured to log the inboundcommunication according to a compliance procedure.
 16. The apparatus ofclaim 13, wherein the one or more trade parameters include a side, aquantity, a ticker, an order type, or an amount.
 17. The apparatus ofclaim 13, the processor further configured to generate an outboundcommunication in response to a missing parameter.
 18. The apparatus ofclaim 17, the network interface device further configured to receive asecond inbound communication included data indicative of the missingparameter in response to the outbound communication.
 19. The apparatusof claim 13, further comprising: a display device configured to displaya window having a boundary defining a perimeter of the window, thewindow comprising a plurality of distinct display areas disposedinternal to said boundary, the plurality of display areas comprising: afirst display area configured to display a first chat text correspondingto a first chat session via a first instant messaging (IM) network; anda second display area configured to display a second chat textcorresponding to a second chat session via a second IM network, thesecond IM network being different from the first IM network.
 20. Theapparatus of claim 13, the processor further configured to convert theone or more trade parameters from the inbound communication to apredetermined protocol.